3 research outputs found

    MALICIOUS TRAFFIC DETECTION IN DNS INFRASTRUCTURE USING DECISION TREE ALGORITHM

    Get PDF
    Domain Name System (DNS) is an essential component in internet infrastructure to direct domains to IP addresses or conversely. Despite its important role in delivering internet services, attackers often use DNS as a bridge to breach a system. A DNS traffic analysis system is needed for early detection of attacks. However, the available security tools still have many shortcomings, for example broken authentication, sensitive data exposure, injection, etc. This research uses DNS analysis to develop anomaly-based techniques to detect malicious traffic on the DNS infrastructure. To do this, We look for network features that characterize DNS traffic. Features obtained will then be processed using the Decision Tree algorithm to classifyincoming DNS traffic. We experimented with 2.291.024 data traffic data matches the characteristics of BotNet and normal traffic. By dividing the data into 80% training and 20% testing data, our experimental results showed high detection aacuracy (96.36%) indicating the robustness of our method

    A Systematic Comparison of Software Requirements Classification

    Get PDF
    Software requirements specification (SRS) is an essential part of software development. SRS has two features: functional requirements (FR) and non-functional requirements (NFR). Functional requirements define the needs that are directly in contact with stakeholders. Non-functional requirements describe how the software provides the means to carry out functional requirements. Non-functional requirements are often mixed with functional requirements. This study compares four primarily used machine learning methods for classifying functional and non-functional requirements. The contribution of our research is to use the PROMISE and SecReq (ePurse) dataset, then classify them by comparing the FastText+SVM, FastText+CNN, SVM, and CNN classification methods. CNN outperformed other methods on both datasets. The accuracy obtained by CNN on the PROMISE dataset is 99% and on the Seqreq dataset is 94%

    Analisis Strategi Migrasi Aplikasi Monolitik ke Microservice Menggunakan Strangler Fig Pattern

    No full text
    Microservice berarti membagi aplikasi monolitik menjadi layanan yang lebih kecil dan saling terhubung. Sistem informasi yang ada di ITS yang dikembangkan dan dikelola oleh DPTSI merupakan aplikasi monolitik berbasis PHP. Saat ini banyak penelitian yang telah dilakukan oleh peneliti sebelumnya merupakan aplikasi monolitik berbasis JAVA yang proses migrasinya ke microservice masih menggunakan satu aplikasi monolitik. Strangler Fig Pattern merupakan strategi migrasi yang lebih baik, karena tidak langsung mematikan aplikasi yang ada namun menghilangkan fungsinya satu persatu. Saat ini strategi migrasi Strangler Fig Pattern hanya diimplementasikan pada satu aplikasi monolitik. Pada penelitian ini, akan dibuat metode migrasi dari aplikasi monolitik berbasis PHP ke microservice berdasarkan Strangler Fig Pattern dan Domain-Driven Design (DDD). Metode migrasi dengan Strangler Fig Pattern akan dimodifikasi agar dapat digunakan pada lebih dari satu aplikasi monolitik. DDD digunakan untuk menentukan domain pada setiap aplikasi monolitik. Terakhir pada penelitian ini juga akan ditunjukkan metode komunikasi antar microservice agar setiap microservice dapat saling terhubung dan menjaga konsistensi data. Penelitian ini menggunakan enam aplikasi monolitik yaitu SIAKAD, myITS Presensi, myITS Classroom, myITS StudentConnect, SIMPEG dan SIMPEL untuk menentukan proses bisnis yang serupa sehingga dapat dijadikan kandidat microservice. Dari keenam aplikasi monolitik tersebut, digunakan pendekatan DDD dengan pengelompokan berdasarkan fungsional sistem dan mengidentifikasi setiap fungsionalnya. Sehingga didapatkan dua kelompok microservice yaitu kelompok Akademik dan Kepegawaian dengan masing-masing memiliki lima kandidat microservice. Kelompok akademik meliputi microservice mahasiswa, FRS, presensi, kelas, portofolio. Sedangkan kelompok kepegawaian yaitu microservice pegawai, litabmas, portofolio, BKD dan PAK. Kandidat microservice yang telah teridentifikasi dibangun dengan Laravel 8 dan dipasang menggunakan teknologi kontainerisasi di Docker. Setiap kandidat microservice memiliki masing-masing database. Dalam menjaga konsistensi data dan komunikasi antar microservice, dibangun juga message bus menggunakan Apache Kafka pada sebuah kontainer Docker. Dengan message bus, komunikasi antar microservice menggunakan event publish-subscribe. Microservice yang menjadi publisher adalah mahasiswa, pegawai, dan litabmas. Sedangkan microservice lainnya berperan sebagai subscriber. Hasil dari pengembangan microservice dan message bus yang dibangun yaitu setiap microservice publisher berhasil menyebarkan data ke microservice subscriber yang membutuhkan. Microservice subscriber juga berhasil menerima data dan mengolahnya sesuai kebutuhan. ==================================================================================================================================== A monolithic application is divided into smaller and interconnected services, which are referred to as microservices. DPTSI builds and manages the ITS information system, which is a monolithic PHP-based application. Many past studies have used monolithic apps built in JAVA. And when shifting from monolithic applications to microservices, they still employ one monolithic application. Strangler Fig Pattern is a method that is ideal for migrating running applications because it does not turn off existing applications immediately but instead eliminates their functionality one by one. The Strangler Fig Pattern migration approach may currently only be used for a monolithic application. We will use the Strangler Fig Pattern and Domain-Driven Design (DDD) to design a migration technique from a PHP-based monolithic application to microservices. The Strangler Fig Pattern migration method will be improved so it can be utilized in several monolithic applications. Each monolithic application's domain is defined using DDD. Finally, this research will illustrate how to communicate amongst microservices so that each one may be connected to the others and data consistency can be maintained. This study uses six monolithic applications: SIAKAD, myITS Presence, myITS Classroom, myITS StudentConnect, SIMPEG, and SIMPEL to determine similar business processes to be used as microservice candidates. The six monolithic applications use the DDD approach by grouping them based on system functionality and identifying each function. So two microservice groups were obtained, the academic and employee groups with each having five microservice candidates. Academic groups include student, FRS, attendance, classes, and portfolios microservices. While the employee group is employee, litabmas, portfolio, BKD, and PAK microservices. The microservice candidate is built with Laravel 8 and installed using containerization technology in Docker. Each microservice candidate has its database. In maintaining data consistency and communication between microservices, a message bus was also built using Apache Kafka in a Docker container. With the message bus, communication between microservices uses the publish-subscribe event. Microservices that become publishers are students, employees, and litabmas. Meanwhile, other microservices act as subscribers. The result of the development of the built microservices and message buses is that each microservice publisher succeeds in spreading data to the microservice subscribers who need it. The microservice subscriber also manages to receive data and process it as needed
    corecore